 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| core1553brt v3.3 handbook
actel corporation, mountain view, ca 94043 ? 2010 actel corporation. all rights reserved. printed in the united states of america part number: 50200093-2 release: august 2010 no part of this document may be copied or reproduced in any form or by any means without prior written consent of actel. actel makes no warranties with respect to this documentati on and disclaims any implied warranties of merchantability or fitness for a particular purpose. information in this doc ument is subject to change without notice. actel assumes no responsibility for any errors that may appear in this document. this document contains confidential proprietary informati on that is not to be disclosed to any unauthorized person without prior written cons ent of actel corporation. trademarks actel, actel fusion, igloo, libero, pigeon point, proasic, smartfusion and the associated logos are trademarks or registered trademarks of actel corporatio n. all other trademarks and service marks are the property of their respective owners. core1553brt v3.3 revision 2 3 table of contents introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 general description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 verification and compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 fail-safe state machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 device requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1 mil-std-1553b bus overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 message types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 word formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 tool flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 smartdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 simulation flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 interface descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 parameters on core1553brt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 i/o signal descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 interface timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 transceiver loopback delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 clock requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5 operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 standard memory address map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 memory address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 interrupt vector extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 status word settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 command word storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 transfer status words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 backend access times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 data transfers ? receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 data transfers ? transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 rt-to-rt transfer support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 mode codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 loopback tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 error detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 built-in test support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 command legalization interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6 testbench operation and modification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 verification testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 vhdl testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 verilog testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 table of contents 4 revision 2 7 implementation hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 external command word legality example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 modifying the backend address map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 modifying the backend interrupt vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 connecting the backend to internal fpga me mory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 buffer management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 bus transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 typical rt systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 8 vhdl testbench procedure and function calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 a list of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 b product support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 customer service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 actel customer technical support center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 actel technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 contacting the customer technical support center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 core1553brt v3.3 handbook revision 2 5 introduction general description core1553brt provides a complete, dual-redundant mi l-std-1553b remote terminal (rt), apart from the transceivers required to inte rface to the bus. a typical system implementation using core1553brt is shown in figure 1 and figure 2 on page 6 . at a high level, core1553brt simply provides a se t of memory-mapped subaddr esses that ?receive data written to? or ?transmit data read from.? the core c an be configured to connect directly to synchronous or asynchronous memory devices. alternatively, t he core can directly connect to backend devices, removing the need for memory buffer s. if memory is used, the core requires 2,048 words of memory, which can be shared with the local cpu. the core supports all 1553b mode codes and allows the user to designate as illegal any mode code or any particular subaddress for both transmit and receive operations. the command legalization can be done within the core or in an external command lega lity block via the command legalization interface. figure 1 ? typical core1553brt system adc memory address mapper backend interface command legality interface command legality checker busainen rcvstba busainp rxdainp busbinen rcvstba busbinp rxdbinp busbinn rxdbinn busboutinh txinha busainn rxdainn busaoutinh txinha busaoutp txdainp busboutp txdbinp busaoutn txdainn busboutn txdbinn transceiver core1553brt actel fpga introduction 6 revision 2 the core consists of si x main blocks: 1553b enc oders, 1553b decoders, th e backend interface, a command decoder, rt controller blocks, and a command legalization block ( figure 2 ). in core1553brt, a single 1553b encoder is used. this takes each word to be transmitted and serializes it, after which the signal is manchester-encoded. the encoder also includes logic to prevent the rt from transmitting for longer than the allowed period, and loopback fail logic. the loopback logic monitors the received data and verifies that the core has co rrectly received every word that it transmits. the output of the encoder is gated with the bus enable signals to select which busses the rt should use to transmit. the core includes two 1553b decoders. a decoder takes the serial manchester data received from the bus and extracts the received data words. a decoder r equires a 12, 16, 20, or 24 mhz clock to extract the data and the clock from the serial stream. the decoder contains a digital pll that generates a recovery clock used to sample the incoming serial data. the data is then deserialized and the 16-b it word decoded. the decoder detects whether a command or data word is received and also performs manchester encoding and parity error checking. the backend interface for core1553brt allows a simple connection to a memory device or direct connection to other devices, such as analog to digi tal converters. the access rates to this memory are slow, with one read or write every 20 s. at 12 mhz o peration, this is one read or write every 240 clock cycles. the backend interface can be configured to connect to either synchronous or asynchronous memory devices. this allows the core to be connected to synchronous logic, memory within the fpga, or external asynchronous memory. the core implements a simple subaddress to the memory address mapping function, allowing the core to be directly connected to a memory block. the co re also supports an address mapping function that allows the backend memory map to be modified to emulate legacy 1553b remote terminals, therefore minimizing system and software changes when adopting core1553brt. associated with this function is the ability to create a user-specific interrupt vector. the backend interface supports a standard bus request and grant protocol and provides a wait input to allow the core to interface to slow memory devices. the command decoder and rt controller blocks dec ode the incoming command words, verifying their legality. then, the protocol state machine responds to the command, transmitting or receiving data or processing a mode code. core1553brt has an internal command legality bl ock that verifies every 1553b command word. a separate interface is provided that, when enabled, allows the command legality decoder to be figure 2 ? core1553brt rt block diagram backend interface memory 2,04816 core1553brt command legalization command decoder rt protocol controller decoder decoder encoder bus a bus b core1553brt v3.3 handbook revision 2 7 implemented outside core1553brt. this external inte rface is intended for use with obfuscated versions of the core. for the rtl version of the core, this in terface can be used, or the source code can be easily modified to implement this function. the external bist interface is used to configure the ex ternal transmit bit word or internal bist word. the external bist is configured when external_bist parameter/generic is set and external bist enable is set. verification and compliance core1553brt functionality has been verified in simu lation and hardware. full functional verification against the rt test plan, as def ined in mil-hdbk-1553a, has been carried out using a vhdl simulation environment. to fully verify compliance, the core has been implemented on an a54sx32a-std part connected to external transceivers and memory. test systems inc. has verified core1553brt against the remote terminal test plan in accordance with the rt validation test plan mil-hdbk-1553a, appendix a. fail-safe state machines the logic design of core1553brt implements fail-safe state machines. all state machines include illegal state detection logic. if a state machine should ever enter an illegal state, the core will assert its fsm_error output and the state machine will reset. if this occurs, actel recommends that the external system reset the core and also asse rt the tflag input to inform the bus controller (bc) that a serious error has occurred within the remote terminal. the fsm_error output can be left un connected if the system is not requi red to detect and report state machines entering illegal states. version this handbook applies to core1553brt v3.3 and later. introduction 8 revision 2 device requirements core1553brt can be implemented in several actel fpga devices. table 1 gives the utilization and performance figures for the core implemented in these devices. the core can operate with a clock of up to 24 mhz. this clock rate is easily met in all actel silicon families noted in ta b l e 1 . utilization data was generated using standard libero id e tool flows with typical core parameter settings. utilization data will vary slightly with diff erent parameter settings and tool usage. table 1 ? device utilization and performance family combinatorial sequential total device utilization performance igloo ? 911 414 1,325 agl600 10% >60 mhz iglooe agle600 igloo plus aglp125v5 43% proasic ? 3a3p600 10% proasic3e a3pe600 proasic3l a3p600l fusion afs600 proasic plus ? 1,305 428 1,733 apa450 14% axcelerator ? 650 417 1,067 ax500 13% >70 mhz rtax-s rtax250s 25% sx-a 633 425 1,058 a54sx72a 18% >35 mhz rtsx-s rt54sx72s revision 2 9 1 ? mil-std-1553b bus overview the mil-std-1553b bus is a differential serial bus used in military and space equipment. it comprises multiple redundant bus connections and communicates at 1 mb/s. the bus has a single active bc and up to 31 rts. the bc manages all data transfers on the bus using the command and status protocol. the bus controller initiates every transfer by sending a command word and data if required. the selected rt will resp ond with a status word and data if required. the 1553b command word contains a 5-bit rt address, transmit or receive bit, 5-bit subaddress, and 5- bit word count. this allows for 32 rts on the bus. however, since rt address 31 is used to indicate a broadcast transfer, only 31 rts can be connected. each rt has 30 subaddresses reserved for data transfers. the other two subaddresses (0 and 31) ar e reserved for mode codes used for bus control functions. data transfers contain up to thirty-two 16-bit data words. mode code command words are used for bus control functions such as synchronization. message types the 1553b bus supports 10 message transfer types, allowing basic point-to-point and broadcast bc-to- rt data transfers, mode code messages, and direct rt-to-rt messages. figure 1-1 shows the message formats. figure 1-1 ? 1553b message formats bc-to-rt transfer receive command data 0 data . . . data n response time status word rt message gap next command bc bc rt-to-rt transfer receive command transmit command response time status word data 0 data . . . rt1 rt2 data n response time status word message gap next command bc bc rt-to-bc transfer transmit command response time status word data 0 data . . . data n rt bc message gap next command bc rt-to-all-rts broadcast receive command transmit command response time status word data 0 data . . . rt bc data n message gap next command bc mode command, no data mode command response time status word message gap next command rt bc bc mode command, rt transmit data mode command response time status word mode data message gap next command rt bc bc mode command, rt receive data mode command mode data response time status word message gap next command rt bc bc broadcast mode command with data mode command mode data message gap next command bc bc broadcast mode command, no data mode command message gap next command bc bc bc-to-all-rts broadcast receive command data 0 data . . . data n message gap next command bc bc mil-std-1553b bus overview 10 revision 2 word formats there are only three types of words in a 1553b mess age: a command word (cw), a data word (dw), and a status word (sw). each word consists of a 3-bit sync pattern, 16 bits of data, and a parity bit, providing the 20-bit word ( figure 1-2 ). figure 1-2 ? 1553b word formats bit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 cw 5 1 5 5 1 sync rt address t/r subaddress word count / mode code p dw 16 1 sync data p sw 5 111 3 111111 sync rt address message error instrumentation service request reserved broadcast busy subsystem flag dynamic bus terminal flag parity revision 2 11 2 ? tool flows smartdesign core1553brt is available for download to the smar tdesign ip catalog, via the libero? integrated design environment (ide) web repository. for information on using smartdesign to instantiate, configure, connect, and generate cores, please refer to the libero ide online help. the core can be configured using the configur ation gui within smartdesign, as shown in figure 2-1 . figure 2-1 ? core1553brt configuration within smartdesign tool flows 12 revision 2 simulation flows to run simulations, the required testbench flow must be selected within smartdesign. the required testbench is selected through the core configurat ion gui. the following simulation environments are supported: ? full 1553 verification environment (vhdl only) ? simple testbench (vhdl and verilog) when smartdesign generates the core, it will instal l the appropriate testbench files. to run the testbenches, simply set the design root to the cor e1553brt instantiation in the libero ide file manager and click the simulation icon in libero ide. this will invoke model sim ? and automatically run the simulation. revision 2 13 3 ? interface descriptions parameters on core1553brt the parameters given in ta b l e 3 - 1 are used to configure the core. table 3-1 ? core1553brt parameters parameter range description family 2 to 23 must be set to the required fpga family: 8: sx-a 9: rtsx-s 11: axcelerator 12: rtax-s 14: proasic plus 15: proasic3 16: proasic3e 17: fusion 20: igloo 21: iglooe 22: proasic3l 23: igloo plus clkspd 12, 16, 20, or 24 sets the clock frequency of the core to 12, 16, 20, or 24 mhz wrttsw 0 or 1 when 1, the core will writ e the transfer status word (tsw) to the memory. when 0, the core disables the writi ng of the transfer status word to memory. this is useful for simple rt app lications that do not use memory but have a direct connection to the backend device. wrtcmd 0 or 1 when 1, the core will write the 1553b command word to the locations used for the tsw values. if wrttsw is also enabled, the command word is written to memory at the start of a message, and the ts w value will overwrite the command word at the end of the message, unless an external address mapping function is used. extmdata 0 or 1 when 1, the core reads and writes mode code data words from and to the external memory (except for ?tra nsmit last command? and ?transmit bit [built-in test] word?). the vword input is not used when this input is active. bcasten 0 or 1 this input enables broadcast operation. when 1, broadcast operations are enabled. when 0, broadcast messages (i.e., rt address 31) are treated as normal messages. if the rtaddr input is set to 31, the rt will respond to the message. interface descriptions 14 revision 2 sa30loop 0 or 1 this input alters the back end memory mapping so that subaddress 30 provides automatic loopback. when 0, the rt does not loop back subaddress 30. separate memory buffers are used for transmit and receive data buffers. when 1, the rt maps the transmit memory buffer for subaddress 30 to the receive memory buffer for suba ddress 30; i.e., t he upper address line is forced to 0. asyncif 0 or 1 when 1, the backend in terface is in asynchronous mode. when 0, the backend interface is in synchronous mode. intenbbr 0 or 1 when active (1), the core generates interrupts when both good and bad 1553b messages are received. when inactive (0), the core only generates interrupts when good messages are received. testtxtouten 0 or 1 this enables the testtxto ut input; it is for test use only. this parameter should be set to 0 if it is not required to be able to force transmission overrun for testing the internal transmit timer. initlastsw 0 or 1 this input controls the last status word. when 0, the first received command is a transmit last status word. the core will respond with an undefined status word since no status word has previously been sent (same func tion as previous core versions.) when 1, the first received command is a transmit last status word. the core will respond with a valid rt address and all other status bits zero, even though no status word was previously sent. it requires purstn to be asserted at power-up. the default value of initlastsw is 0. external_bist 0 or 1 this parameter controls the mode code 19 support. when 0, the internal bist value as specified in table 5-6 on page 34 is returned in response to the transmit bist mode code. when 1, the input bitin [ 15:0] is returned in response to the transmit bist mode code. the default value of external_bist is 0. table 3-1 ? core1553brt parameters (continued) parameter range description core1553brt v3.3 handbook revision 2 15 i/o signal descriptions table 3-2 lists the signals for the 1553b bus interface. table 3-3 on page 15 lists the control and status signals. table 3-2 ? 1553b bus interface port name type description rtaddr[4:0] in sets the rt address; rt address can be set to ?11111? for normal operation only when bcasten is set to 0. rtaddrp in rt address parity input. this input should be set high or low to achieve odd parity on the rtaddr and rtaddrp inputs. if rtaddr is '00000', the rtaddrp input should be 1. rtaderr out indicates that the rtaddr and rtaddrp inputs have incorrect parity, or broadcast is enabled, and the rt address is set to 31. when active (high), the rt is disabled and will ignore all 1553b traffic. busainen out active high output that enables for the a receiver busainp in positive data input from the a receiver busainn in negative data input from the a receiver busbinen out active high output t hat enables for the b receiver busbinp in positive data input from the bus to the b receiver busbinn in negative data input from the bus to the b receiver busaoutin out active high transmitter inhibit for the a transmitter busaoutp out positive data output to the bus a tr ansmitter (held high when no transmission) busaoutn out negative data output to the bus a transmitter (held high when no transmission) busboutin out active high transmitter inhibits the b transmitter busboutp out positive data output to the bus b tr ansmitter (held high when no transmission) busboutn out negative data output to the bus b transmitter (held high when no transmission) table 3-3 ? control and status signals port name type description clk in master clock input (12, 16, 20, or 24 mhz) rstn in reset input asynchronous (active low) srequest in directly controls the servic e request bit in the 1553b status word rtbusy in directly controls the busy bit in the 1553b status word ssflag in directly controls the subsystem flag bit in the 1553b status word tflag in controls the subsystem flag bit in t he 1553b status word. this can be masked by the "inhibit terminal flag bit" mode code. vword[15:0] in provides the 16-bit vector value for the "transmit vector word" mode command busy out indicates that the 1553b rt is either receiving or transmitting data or handling a mode command cmdsync out pulses high for a single clock cycle when the rt detects the start of a 1553b command word (or status word) on the bu s. provides an early signal that the rt may be about to receive or transmit data or mode code. note: all control inputs except rstn are synchronous and sampled on the rising edge of the clock. all status outputs are synchronous to the rising edge of the clock. interface descriptions 16 revision 2 msgstart out pulses high for a single cycle when the rt is about to start processing a 1553b message whose command has been validated for this rt. syncnow out pulses high for a single clock cycle when the rt receives a ?synchronize? (with or without data mode) command. the pulse occurs just after the 1553b command word (sync with no data) or data word (sync with data mode code) has been received. busreset out pulses high for a single clock cycl e whenever the rt receives a ?reset mode? command. the core logic will also automat ically reset itself on receipt of this command. intout out goes high when data has been received or transmitted or a mode command processed. the reason for the interrupt is provided on intvect. this output will stay high until intack goes high. if intack is held high, this output will pulse high for a single clock cycle. intvect[6:0] out this 7-bit value contains the reason for the interrupt. it indicates which subaddress data has been received or transmitted. bit 6: 0: bad block received 1: good block received bit 5: 0: rx data 1: tx data bits 4: 0:subaddress further information can be found by checki ng the appropriate transfer status word for the appropriate subaddress. intack in interrupt acknowledge input. when hi gh, this resets intout back to low. if this input is held high, the intout signal will pulse high for one clock cycle every time an interrupt is generated. memfail out goes high if the core fails to read dat a from or write data to the backend interface within the required time. this can be caused by the backend not asserting memgntn fast enough or asserting memwaitn for too long. clrerr in used to clear memfail and other inte rnal error conditions. must be held high for more than two clock cycles. testtxtout in this input is for test use only. it should be tied low. when high and the testtxtouten parameter is set to 1, the rt will transmit more than 32 data words if a ?transmit data? command word is received. this will cause the rt to shut down the transmitter and set the timeout bits in the bit word. fsm_error out this output will go high for a sing le clock cycle if any of the internal state machines enter an illegal state. this output should not go high in normal operation. should it go high, it is recommended that the core be reset. purstn in asynchronous power-up reset input (activ e low) that is used to initialize the last status word value. this input is vali d only when the parameter initlastsw = 1. bitinen in transmit bit word enable input (active high). this input is valid when parameter external_bist = 1 (to support mode code 19). bitin[15:0] in transmit bit word input. this inpu t is valid when the parameter external_bist = 1. table 3-3 ? control and status signals (continued) port name type description note: all control inputs except rstn are synchronous and sampled on the rising edge of the clock. all status outputs are synchronous to the rising edge of the clock. core1553brt v3.3 handbook revision 2 17 command legalization interface the core checks the validity of al l 1553b command words. in rtl and obfuscated versions of the core, the logic may be implemented externally to the core . the command word is provided, and the logic must generate the command-valid input. the command legal ization interface also provides two strobes that are used to latch the command value to enable it to be used for address mapping and interrupt vector extension functions ( table 3-4 ). table 3-4 ? command legalization interface port name type description useextok in when 0, the core uses its own internal command-valid logic, enabling all legal, supported mode codes and all subaddresses. when 1, the core disables its internal logic and uses the external cmdokay input for command legality. cmdval[11:0] out active command 11: 0: non-broadcast 1: broadcast 10: 0: receive 1: transmit 9:5: subaddress 4:0: word count / mode code these outputs are valid throughout the complete 1553b message. they can also be used to steer data to particular back end devices. in particular, bit 11 allows non-broadcast and broadcast messages to be differentiated, as required by mil- std-1553b, notice 2. cmdstb out single-clock-cycle pulse that indicates valid command is received on cmdval. cmdokay in command word is okay (active high). the external logic must set this within 2 s from the cmdval output changing. cmdokout out command word is okay (output). when useextok = 0, the core puts out its ?internal command word okay? validation signal. addrlat out cmdval address latch enable outpu t (active high). used to latch cmdval when it is being used for an address mapping function. addrlat should be connected to the enable of a rising-edge clock flip-flop. intlat out cmdval interrupt vector latch enabl e output (active high). used to latch cmdval when it is being used for an extended interrupt vector function. intlat should be connected to the enable of a rising-edge clock flip-flop. interface descriptions 18 revision 2 backend interface the backend interface supports both synchronous operation (to the core clock) and asynchronous operation to backend devices ( table 3-5 ). table 3-5 ? backend signals port name type description memreqn out memory request (active low) output. the backend interface requires memory access completion within 10 s of me mreq going low to avoid data loss or overrun on the 1553b interface.* memgntn in memory grant (active low) input. this input should be synchronous to clk and needs to meet the internal register se tup time. this input can be held low if the core has continuo us access to the ram. memwrn out memory write (active low) synchronous mode: this output indicates that data is to be written on the rising clock edge. asynchronous mode: this output will be low for a minimum of one clock period and can be extended by the memwaitn input. the address and data are valid one clock cycle before memwrn is active and held for one clock cycle after memwrn goes inactive. memrdn out memory read (active low) synchronous mode: this output indica tes that data will be read on the next rising clock edge. this signal is intended as the read signal for synchronous rams. asynchronous mode: this output will be low for a minimum of one clock period and can be extended by the me mwaitn input. the address is valid one clock cycle before memrdn is acti ve and held for on e clock cycle after memrdn goes inactive. the data is sampled as memrdn goes high. memcsn out memory chip select (active lo w). this output has the same timing as memaddr. memwaitn in memory wait (active low) synchronous mode: this input is not used; it should be tied high. asynchronous mode: indicate s that the backend is not ready, and the core should extend the read or write st robe period. this input should be synchronous to clk and needs to meet the internal register setup time. it can be permanently held high. memoper[1:0] out indicates the type of memory access being performed. 00: data transfer for both data and mode code transfers 01: tsw 10: command word 11: not used memaddr[10:0] out memory address output (t he subaddress mapping is covered in "standard memory address map" on page 19 ) memdout[15:0] out memory data output memdin[15:0] in memory data input note: *the 10 s refers to the time from memreqn being asserted to the core deasserting its memreqn signal. the core has an internal over head of five clock cycles, and any inserted wait cycles will also reduce this time. this time increases to 19.5 s if the wrttsw and wrtcmd inputs are low. core1553brt v3.3 handbook revision 2 19 standard memory address map core1553brt requires an external 2,04816 memory device. this memory is split into sixty-four 32- word data buffers. each of the 30 subaddresses has a receive and a transmit buffer, as shown in table 3-6 . the memory allocated to the unused receive s ubaddresses 0 and 31 is used to provide status information back to the rest of th e system. at the end of every tran sfer, a tsw is written to these locations. memcen out control signal enable (active high). this signal is high when the core is requesting the memory bus and has bee n granted control. it is intended to enable any tristate drivers that may be implemented on the memory control and address lines. memden out data bus enable (active high). this signal is high when the core is requesting the memory bus, has been granted control, and is waiting to write data. it is intended to enable any bidirectional driv ers that may be implemented on the memory data bus. table 3-6 ? standard memory address map address ram contents action 000?01f rx transfer status words the core only writes to these addresses (except when sa30loop is high). 020?03f receive subaddress 1 ... ... 3c0?3df receive subaddress 30 3e0?3ff tx transfer status words 400?41f not used the core only reads from these addresses. 420?43f tx transfer subaddress 1 ... ... 7c0?7df tx transfer subaddress 30 7e0?7ff not used table 3-5 ? backend signals (continued) port name type description note: *the 10 s refers to the time from memreqn being asserted to the core deasserting its memreqn signal. the core has an internal over head of five clock cycles, and any inserted wait cycles will also reduce this time. this time increases to 19.5 s if the wrttsw and wrtcmd inputs are low. revision 2 21 4 ? interface timing specifications memory write timing ? asynchronous mode figure 4-1 ? memory write timing ? asynchronous mode table 4-1 ? memory write timing sync mode description time t pwwr write pulse width (no wait states) 1 clock cycle t pdgnt maximum delay from memreqn to memgntn active 12.0 s t sudata data setup time to memwrn low 1 clock cycle t suaddr address setup time to memwrn low 1 clock cycle t hddata data hold time from memwrn high 1 clock cycle t hdaddr address hold time from memwrn high 1 clock cycle t suwait wait setup to rising clock edge 1 clock cycle valid operation valid data clk memreqn memgntn memcen memcsn memoper memdata memwrn memwaitn memden addrlat valid address memaddr interface timing 22 revision 2 memory read timing ? asynchronous mode figure 4-2 ? memory read timing table 4-2 ? memory read timing async mode description time t pwrd read pulse width (no wait states) 1 clock cycle t pdgnt maximum delay from memreqn to memgntn active 12.0 s t suaddr address setup time to memrdn low 1 clock cycle t hdaddr address hold time from memrdn high 1 clock cycle t suwait wait setup to rising clock edge 15.0 ns t sudata data setup time to memrdn high 15.0 ns valid operation data clk memreqn memgntn memcen memcsn memoper memdata memrdn memwaitn memden addrlat valid address memaddr core1553brt v3.3 handbook revision 2 23 memory write timing ? synchronous mode figure 4-3 ? memory write timing address data data written here clk memreqn memgntn memcen memcsn memaddr memdata memwrn memden addrlat memoper operation interface timing 24 revision 2 memory read timing ? synchronous mode command word legality interface timing figure 4-4 ? memory read timing figure 4-5 ? command word legality interface timing table 4-3 ? command word legality interface timing name description time t pdcmdok maximum external command word legality decode delay 3 s clk addrlat memoper operation address memreqn memgntn memcen memcsn memaddr memden data memdata memrdn data sampled here clk cmdval cmdok cmdstb previous command current command core1553brt v3.3 handbook revision 2 25 address mapper timing interrupt vector extender timing rt response times rt response time is from the midpoint of the parity bit in the command word to the midpoint of the status word sync ( ta b l e 4 - 4 ). the rt-to-rt timeout is from the first command word parity bit to the expected sync of the first data word. note: this figure shows the worst-case timing when a second 1553b command arrives as the core starts a backend transfer and memgntn is held low. figure 4-6 ? address mapper timing note: this figure shows the worst-case timing when a second 1553b command arrives as the core asserts an interrupt request. also, intlat may be acti ve for several clock cycles prior to intout. figure 4-7 ? interrupt vector extender timing table 4-4 ? rt response times spec description at 12 mhz at 16 mhz at 20 mhz at 24 mhz t rtresp rt response time 4.75 to 7.0 s 4.75 to 7.0 s 4.75 to 7.0 s 4.75 to 7.0 s t rtrtto rt-to-rt timeout 57 s 57 s 57 s 57 s t xxto transmitter timeout 704 s 668 s 691 s 693 s clk cmdval addrlat memreqn memcsn current command next command clk cmdval intlat intout current command next command interface timing 26 revision 2 transceiver loopback delays core1553brt verifies that all transmitted data words are correctly transmitted. as data is transmitted by the transceiver on the 1553b bus, the data on the bus is monitored by the transceiver and decoded by core1553brt. the core requires that the loopback delay, i.e., the time from busaoutp to busainp, be less than the values given in the ta b l e 4 - 5 . the loopback delay is a function of the internal fpga delay, pcb routing delays, and internal transceiver delay as well as transmission effects from the 1553b bus. additional register stages can be inserted on either the 1553b data input or output within the fpga, providing the loopback delays in table 4-5 are not violated. this is recommended if additional gating lo gic is inserted inside the fpga between the core and transceiver to minimize skew between the differential inputs and outputs. clock requirements to meet the 1553b transmission bit rate requirem ents, the core1553brt clock input must be 12 mhz, 16 mhz, 20 mhz, or 24 mhz 0.1% (+/- 1000 hz) long term and 0.01% (+/- 100 hz) short term. table 4-5 ? transceiver loopback requirements clock speed maximum loopback delay 12 mhz 2.50 s 16 mhz 2.50 s 20 mhz 2.45 s 24 mhz 2.40 s revision 2 27 5 ? operation standard memory address map core1553brt requires an external 2,04816 memory device. this memory is split into sixty-four 32- word data buffers. each of the 30 subaddresses has a receive and a transmit buffer, as shown in table 5-1 . the memory allocated to the unused receive s ubaddresses 0 and 31 is used to provide status information back to the rest of the system. at the end of every transfe r, a transfer status word is written to these locations. if the sa30loop input is set high, the rt maps tran smit subaddress 30 to receive subaddress 30; i.e., the upper address bit is forced to 0. this prov ides a loopback subaddress, as per mil-std-1553b, notice 2. the tsw is still written to address 03ee. it should be noted that this is not strictly compliant with the specification, since the transmit buffer will contain in valid data if the received command fails, e.g., with a parity error. the transm it buffer should only be updated if the receive command had no errors. to implement this function in fu ll compliance, the sa30loop input should be tied low, and the rt backend should copy the receive memory buffer to the transmit memory buffer only after the rt signals that the message was received with no errors. table 5-1 ? standard memory address map address ram contents action 000?01f rx transfer status words the core on ly writes to these addresses (except when sa30loop is high). 020?03f receive subaddress 1 ... ... 3c0?3df receive subaddress 30 3e0?3ff tx transfer status words 400?41f not used the core only reads from these addresses. 420?43f tx transfer subaddress 1 ... ... 7c0?7df tx transfer subaddress 30 7e0?7ff not used operation 28 revision 2 when the memory buffer is implemented within the fpga using dual-port rams, separate receive and transmit ram blocks can be used (e ach as 1 k words), as shown in figure 5-1 . in these cases, the rx memory is selected when a10 = 0 and the tx memory when a10 = 1. in this case, the sa30loop input must be tied low. memory address mapping the core supports an external memory address map per that allows the rt memory allocation to be easily customized. to use this function, the cmdval output must be latched by the addrlat signal as shown in figure 5-2 . then, the address mapper function can map the 1553b command words, data words including mode code data, and transfer status words to any memory address. figure 5-1 ? using internal fpga memory blocks command legality block tx memory write read rx memory read write backend interface command legality interface busainen busainp busbinen busbinp busbin busainh busainn busainh busaoutp busboutp busaoutn busboutn core1553brt figure 5-2 ? memory address mapping dq lq set clr cmdval clk1553 addrlat memaddr memoper address mapper function mapped address core1553brt v3.3 handbook revision 2 29 interrupt vector extension the core generates a 7-bit interrupt vector that contains the subaddress and whether it was a transmit or receive message. some systems may need to incl ude whether the message was a broadcast, a mode code, or the actual word count in the interrupt vect or. the core supports an interrupt vector extension function, similar to the address mapper func tion using the intlat signal, as shown in figure 5-3 . status word settings core1553brt sets bits in the 1553b status word in compliance with mil-std-1553b. this is summarized in ta b l e 5 - 2 . command word storage at the start of every 1553b bus transfer, the 1553b command word is written to ram locations 000?01f for receive operations and 3e0?3ff for transmit operations. the address used is as follows: ? cmd location, rx commands: '000000' and sa ? cmd location, tx commands: '011111' and sa if the rt is implemented without a memory-based backend, the writing of the command word can be disabled (wrtcmd input). this simplifies the design of the backend logic that directly controls the backend function. figure 5-3 ? interrupt vector extension cmdval clk1553 intlat intvect interrupt vector extender extended interrupt vector dq lq set clr table 5-2 ? status word bit settings bit(s) function setting 15:11 rt address equals the rtaddr input. 10 message error set whenever the rt detects a message error. 9 instrumentation always 0 8 service request controlled by the ssflag input. 7:5 reserved always 000. 4 broadcast received set whenever a broadcast message is received. 3 busy controlled by the rtbusy input. 2 subsystem flag controlled by the ssflag input. 1 dynamic bus acceptance always 0. core1553b rt does not operate as a bus controller. 0 terminal flag controlled by the tflag input. if an ?inhibit terminal flag? mode code is in effect, will be 0. operation 30 revision 2 transfer status words at the end of every 1553b bus transfer, a transfer st atus word is written to the ram in locations 000?01f for receive operations and 3e0?3ff for transmit operations. the address used is as follows: ? tsw location, rx commands: '000000' and sa ? tsw location, tx commands: '011111' and sa as an example, the tsw address for a transmit command with subaddress 24 would be '01111110100' (3f4h). the tsw contains the information in ta b l e 5 - 3 . if the rt is implemented without a memory-based ba ckend, the writing of the tsw can be disabled. this simplifies the design of the backend logic that directly controls backend functions. backend access times during normal operation, the backend must allow a memory access to complete within 19.5 s. when either the command word or the tsw is written to memory, the backend must be capable of completing memory accesses in 10 s. while the status word is being transmitted, the core must write the command word to memory and fetch the first data word. two memory accesses are perfo rmed in the 20 s that the status word takes to transmit. at the end of a ?broadcast receive? command, co re1553brt writes the last data word and the tsw value before the rt decodes the next command. two memory accesses occur in the 20 s that the command word is being decoded. the core includes a timer that is set to terminate backend memory access at 19.5 s or 10.0 s when either wrtcmd or wrttsw are active. table 5-3 ? transfer status word bit(s) name description 15 used set to 1 at the end of th e transmit or receive command. 14 okay indicates that no errors are detec ted; i.e., bits 11 to 5 are all 0. 13 busn indicates on which bus the command was received: 0: busa 1: busb 12 broadcast indicates a broadcast command. 11 lpbkerrb indicates that the lo opback logic detected an error in the transmitted data for bus b. 10 lpbkerra indicates that the lo opback logic detected an error in the transmitted data for bus a. 9 illegal cmd the command was illegal. a request to transmit from either an illegal subaddress or an illegal mode code was received. 8 memiferr indicates that the dma memory access failed to comp lete quickly enough. 7 manerr indicates that a manchester encoding error was detected in the incoming data. 6 parerr indicates that a parity error was detected in the incoming data. 5 wcnterr indicates that an incorrect number of words was received. 4:0 count sa1 to sa31 indicates the number of words received or transmitted for that subaddress. if wcnterr is 0, '00000' indicates 32 words. otherwise, '00000' indicates zero words transferred. sa0 or sa31 indicates which mode code was received or transmitted per the 1553b specification. core1553brt v3.3 handbook revision 2 31 data transfers ? receive when a ?receive data transfer? comm and is detected, the core will decode each incoming word. at the end of each word, the core will assert memreqn. when memgntn goes low, the core will write the data word to memory and release memreqn. this pr ocess is repeated until the correct number of words has been transferred. the core will then transmit its 155 3b status word. finally, the tsw is also written to memory. data transfers ? transmit when a ?transmit data transfer? comm and is detected, the core will trans mit its status word and assert memreqn. when memgntn goes low, the core will read a data word from memory and release memreqn. once the word is available, the core will transmit the data word. the core will continue to request data from the memory interf ace until the required number of words has been transferred. finally, the tsw is written to memory. rt-to-rt transfer support the core supports rt-to-rt transfers. if a transmitti ng core does not start transferring data within the required time, the core will detect this and set the wcnterr bit in the transfer status word. mode codes when the core receives a mo de code, it first checks its command validity. if the command is valid, it is processed in accordance with the spec ification. otherwise, the message error bit will be set in the 1553b status word. table 5-4 lists the supported mode codes. two mode codes, (1) ?transmit a vector word? and (2 ) ?synchronize with data,? require external data. when extmdata is inactive, the vector word value is set by the vword input, and the ?synchronize with data? word is discarded. when extmdata is acti ve, these values are read from and written to memory. the memaddr output will be similar to a single-word data transfer message; bit 10 will reflect the command word tx bit, and bits 9:5 will be 00h or 1fh, depending on whether the mode code subaddress is set to 0 or 31. bits 4:0 will be zero. this implies the vector word will be read from location 400h or 7e0h, and the ?synchronize with data? wo rd is written to location 000h or 3e0h, depending on whether subaddress 0 or 31 is used. when both wrtcmd and wrttsw are active for each message, the command word and tsw value will be written to the same location; these writes can be distinguished by the memoper output. this may cause some system problems, but this can be avoided by implementing an external address mapper function to map these accesses to different addresses. table 5-4 ? supported mode codes t/r bit mode code function and effect data word core supports broadcast allowed 1 00000 0 dynamic bus control the core does not support bus controller functions, so it will set the message error and dynamic bus control bits in the status word. no no no 1 00001 1 synchronize the core will assert its syncnow output after the command word has been received. no yes yes 1 00010 2 transmit status word the core retransmits the last status word. no yes no operation 32 revision 2 loopback tests core1553brt performs loopback testing on all of its transmissions. the transmit data is fed back into the receiver, and each transmitted word is compared. if an e rror is detected, the loopba ck fail bit is set in the tsw and also in the bit word. 1 00011 3 initiate self-test the core does not support self-test. since the core supports the ?transmit bit word? mode code, this command is treated as legal and will not set message error. no yes yes 1 00100 4 transmitter shutdown the core will disable the encoder on the other bus. no yes yes 1 00101 5 override shutdown the core will re-enable the encoder on the other bus. no yes yes 1 00110 6 inhibit terminal flag the core will mask the tflag input, and the terminal flag bit in the status word will be forced to zero. no yes yes 1 00111 7 override inhibit terminal flag the core will re-enable the tflag input. no yes yes 1 01000 8 reset remote terminal the core will assert its busreset output after the command word has been received. it will also reset itself. no yes yes 1 10000 16 transmit vector word the core will transmit a single data word that contains the value on the vword input. yes yes no 1 10010 18 transmit last command word the core will transmit a single data word that contains the last command word received. yes yes no 1 10011 19 transmit bit word the core will transmit a single data word that contains the extended core status information. the value of this word is defined in table 5-6 on page 34 . yes yes no 0 10001 17 synchronize with data the core will assert its syncnow output after the data word has been received. yes yes yes 0 10100 20 selected transmitter shutdown the core only supports two busses. hence, this command is illegal. the message error bit in the status word will be set. yes no yes 0 10101 21 override selected transmitter shutdown the core only supports two busses. hence, this command is illegal. the message error bit in the status word will be set. yes no yes table 5-4 ? supported mode codes (continued) t/r bit mode code function and effect data word core supports broadcast allowed core1553brt v3.3 handbook revision 2 33 error detection table 5-5 gives action for error conditions detected. table 5-5 ? error detection error condition action command word 1. parity or manchester encoding errors 2. incorrect sync waveform command is ignored. no interrupt generated. mode codes 1. illegal mode code or invalid subaddress (from internal or external legality block) msgerr in sw is set, and the sw is transmitted. message failure interrupt generated. broadcast data commands 1. tx bit set in command word data transfer is aborted. msgerr in sw is set, and the sw is not transmitted. message failure interrupt generated. data word 1. parity or manchester encoding errors 2. incorrect number of words received 3. data words are continuous. 4. incorrect sync waveform data transfer is aborted. msgerr in sw is set, and the sw is not transmitted. message failure interrupt generated. rt-to-rt 1. first command word must be rx. 2. second command word must be tx and non- broadcast. 3. rx rt checks the tx sw and verifies the sync pattern, rt address, msgerr, and busy fields. 4. the first data word sync must be received within 57 s of the command wo rd parity bit. data transfer is aborted. msgerr in sw is set, and the sw is not transmitted. message failure interrupt generated. transmit data error 1. the rt monitors its transmissions on the bus through its decoder and verifies that the correct data is transmitted with no manchester or parity errors. data transfer is aborted. msgerr in sw is set, and the sw is not transmitted. message failure interrupt generated. backend failure 1. the rt makes sure that the backend responds to read and write cycles within the required time. data transfer is aborted. msgerr in sw is set, and the sw is not transmitted. message failure interrupt generated. busy 1. backend rtbusy input is active at any point during the message. data transfer is aborted. busy in sw is set, and the sw is transmitted. message failure interrupt generated. transmitter overrun 1. transmits for greater than 668 s. the internal state machines prevent this from happening, but the core includes the required timer and functionality. this is implemented separately to the encoder to provide complete protection. core shuts down transmissions on bus. operation 34 revision 2 built-in test support core1553brt provides a bit word. this is used to communicate fail in formation back to the bus controller. the bit word contains the information in ta b l e 5 - 6 . table 5-6 ? bit word bit(s) function description 15 businuse indicates on which bus the transmit bit word command was received: 0: bus a 1: bus b 14 lpbkerrb indicates that the lo opback logic detected an erro r on the transmitted data for bus b. this bit is cleared by the clrerr input. 13 lpbkerra indicates that the lo opback logic detected an erro r on the transmitted data for bus a. this bit is cleared by the clrerr input. 12 shutdownb indicates that bus b is shut do wn. this occurs after a ?transmitter shutdown? mode code is received or the hardw are timer detected that the core transmitted for longer than 668 s on bus b. 11 shutdowna indicates that bus a is shut do wn. this occurs after a ?transmitter shutdown? mode code is received or the hardw are timer detected that the core transmitted for longer than 668 s on bus a. 10 tflaginh terminal flag inhibit setting 9 wcnterr a word count error has occurred. this bit is cleared by the clrerr input. 8 manerr a manchester encoding error has occurred. this bit is cleared by the clrerr input. 7 parerr a parity error has occurred. this bit is cleared by the clrerr input. 6 rtrtto the transmitting rt did not provid e data on rt-to-rt transfer. this bit is cleared by the clrerr input. 5 memfail the backend memory interface failed to complete an access within the required time. this bit is cleared in the clrerr input. 4:0 version indicates the core version: '00001': version 2.0 '00010': version 2.1 '00011': version 2.12 '00100': version 2.2 '00101': version 2.21 '01000': version 3.0 '01001': version 3.1 '01010': version 3.2 '01011': version 3.3 core1553brt v3.3 handbook revision 2 35 command legalization interface 1553b commands can be legalized in two ways with core1553brt. for rtl versions, one of the modules in the source code can be edited to l egalize or make illegal command words based on the subaddress, mode code, word count , or broadcast fields of the co mmand word. for obfuscated and rtl versions, external logic can be used to decode the legal/illegal command words ( figure 5-4 ). the user customization logic block takes in cmdval and simply sets cmdokay for all legal command words. the cmdval encoding is given in ta b l e 5 - 7 . the external logic must implement this function within 3 s. figure 5-4 ? command legalization logic table 5-7 ? cmdval encoding bit(s) function description 11 broadcast '1' indicates broadcast; i.e., the rt address was set to 31 in the 1553b command word. 10 transmit or receive tx/rx field from the 1553b command word. '0' indicates receive and '1' transmit. 9:5 subaddress subaddress field from the 1553b command word 4:0 word count mode code word count field from the 1553b command word. when the subaddress is 0 or 31, this contains the 1553b mode code. core1553brt useextok cmdval[11:0] cmdokay user customization logic actel fpga '1' revision 2 37 6 ? testbench operation and modification verification testbench actel has developed a 1553b verification testbench ( figure 6-1 ) that you can use to verify core performance per the 1553b specificat ion. the testbench is coded in vhdl and contains four core1553b remote terminals connected to a bus control functi on and backend interfaces. a procedural testbench controls the various blocks and implements the test s. the source code is not made available with obfuscated licenses of the core. the testbench includes four rts to test core variants , each with different setups of the core configuration inputs ( table 6-1 ). the testbench uses a command word legality module that disables subaddresses 26 and 27 for transmit commands. for receive commands, subaddress 25 is disabled, and subaddress 27 is only enabled for figure 6-1 ? verification testbench table 6-1 ? verification testbench rt configuration rt clock speed memory interface command word legality* 0 variable synchronous internal 1 16 mhz asynchronous internal 2 16 mhz synchronous internal 3 16 mhz asynchronous external note: *all command word legality interfaces are external for obfuscated simulation. backend cw legality core1553b rt 0 tcv backend cw legality tcv backend cw legality tcv backend cw legality tcv 1553b busses core1553b rt 1 core1553b rt 2 core1553b rt 3 tcv tcv tcv tcv procedural 1553b testbench bus control (encoder and decoder) bus monitor bus control (encoder and decoder) bus monitor testbench operation and modification 38 revision 2 word counts 1 to 9. "external command word legality example" on page 54 shows the source code for a command legality module implementing this behavior. the procedural testbench has direct control of th e bus control modules, t he transceivers, and the backend interfaces (including all the backend core in puts). this direct control allows the testbench to initialize the backend ram contents and to verify t he contents after each transfer. the bus controller function has the capability of injecting errors and varying the data rate to verify the 1553b decoder behavior. during operation, the testbench verifies all command , data, and status words. all memory accesses are verified, and the resultant transfer status word for every message is checked. during invocation, the top-level generics can be set to alter the simulation. these generics are specified in table 6-2 . when you run the testbench, it asks which tests you w ant to run. the options are as follows (the options are summarized in table 6-3 on page 39 ): # 1553b test harness - actel ip solutions group # production release 3.3 19 august 2010 # # test options # 1 : quick run # 2 : actel tests - standard mode # 3 : actel tests - address mapper enabled # 4 : rt test plan # 5 : actel tests - short mode (i.e. fewer tests) # 9 : do everything # a : do everything, monitors off and quit # b : turn on bus monitors # r : turn on ram monitors # p : pause simulation - allows waves to update # x : run for a single 1553b word; i.e. 20s # m : send a message m bus rt tx sa wc [seed inc] # d : display rt memory d rt tx sa # s : set rt memory s rt tx sa seed inc # q : quit # # enter option, for demo use 1 ? table 6-2 ? verification testbench rt configuration generic type default value function enbusmon boolean false enables the bus m onitor function. the testbench displays every 1553b word that is transmitted on the busses. enrammon boolean false enables the ram mo nitor function. the testbench displays all the memory reads and writes performed by each of the cores. runtest integer 0 allows the testbench to ru n without user input. forces the testbench to run the test number as defined by the menus (see below). if runtest is gr eater than 10, the testbench runs test number (n ? 10) and quits; for example, if n = 12, the testbench runs test numbe r (12 ? 10 = 2), which is ?actel tests ? standard mode,? and then quits the simulation. core1553brt v3.3 handbook revision 2 39 table 6-3 ? verification testbench menu summary menu command action quick run runs a few simple 1553b command sequences to demonstrate that the core is functioning. actel tests ? standard mode runs the complete set of actel verification tests. for the rtl code ( verif_rtl directory), this takes several hours, depending on the computer used. for the obfuscated version, the simulati on time is significantly longer. rt test plan this implements a subset of the protocol tests specified in the mil-hdbk- 1553a handbook. this takes a very l ong time to run, as thousands of 1553b command words need to be transmitted and verified. do everything this runs the three options listed above, i.e., quick, actel, and test plan. actel tests ? address mapper enabled this runs the standard mode tests but uses an address mapping function (as on testbench operation and modification 40 revision 2 interactive operation the verification testbench allows you to create 1553b messages and transmit from the simulator command line. three commands are pr ovided that support this feature (m, s, and d). their parameters are given below. all parameters are decimal intege rs separated by spaces or commas. if a number begins with ?#,? ?a?f,? or ?a?f,? it is interpre ted as a hexadecimal value. basic error checking is performed on the entered values. message parameter m consider the following example: m bus rt tx sa wc [seed [inc]] ? m ? transmit a message ? bus ? specifies the bus to use, 0 or 1 ? rt ? specifies the rt number, 0?31 ? tx ? rt transmit or receive: 1 = transmit, 0 = receive ? sa ? subaddress to use, 0?31 ? wc ? number of words to transmit or receive, 0?32 ? seed ? sets the first data used fo r the message to this value. if t he rt is to rece ive data, the bus controller transmits the data. if the rt is to transmit, the testbench initializes the rt backend ram for the appropriate subaddress. if no data is provided, the rt receive data is '0000', and the transmit data is whatever the rt memory contains. ? inc ? increments each data word in the message by this value. if not specified, defaults to zero so all data words contain the same value. message parameter s consider the following example: s rt tx sa seed [inc] ? s ? set rt memory ? rt ? specifies the rt number, 0?31 ? tx ? rt transmit or receive memory: 1 = transmit, 0 = receive ? sa ? which subaddress, 0?31 ? seed ? sets the first data value ? inc ? increments each data word in the message by this value. if not specified, defaults to zero so all data words contain the same value. message parameter d consider the following example: d rt tx sa ? d ? display rt memory ? rt ? specifies the rt number, 0?31 ? tx - rt transmit or receive memory: 1 = transmit, 0 = receive ? sa ? which subaddress, 0?31 core1553brt v3.3 handbook revision 2 41 verification tests the verification testbench includes test procedures to check the following: simple messages bc?rt and rt?bc ? subaddress word count combinations rt-to-rt messages mode codes ? verifies all codes broadcast ? status word settings ? all mode codes verified illegal commands (legality interface) ? mode code ? disabled subaddresses ? normal, rt-to-rt, and broadcast ? internal and external legality logic special features ? subaddress 30 loopback ? tsw enabled and disabled ? command word memory write enabled and disabled ? address mapping functions ? interrupt vector extension functions error conditions ? variable bit rates 10,000 hz (1%) ? variable backend gnt and wait delays ? parity and manchester encoding errors ? synchronization pattern corruption ? rt-to-rt illegal command words ? word count errors ? word gaps ? transmitter timeout ? status word flag bits ? superseding command acceptance ? rt address parity logic ? receive on disabled bus ? transmitter overrun ? bit word values ? loopback logic ? extra command and data words ? noise on the data bus ? superseding commands on second bus testbench operation and modification 42 revision 2 vhdl testbench actel provides an example testbench that you can use as the starting point for design verification of the core in your design. a block diag ram of the testbench is shown in figure 6-2 . the testbench creates an rt system (qrtsystem) by adding the transceivers, backend interface, and command legality interface to the core. the top level (qt bench) includes four of these cores. all the cores in this case are identical. the source code modules used are listed in table 6-4 on page 43 . figure 6-2 ? vhdl testbench backend cw legality core1553b rt 0 tcv 1553b busses core1553b rt 1 core1553b rt 2 core1553b rt 3 tcv tcv tcv tcv bus control (encoder and decoder) bus monitor bus control (encoder and decoder) bus monitor rt system rt system rt system rt system user control circuit backend cw legality backend cw legality backend cw legality tcv tcv tcv core1553brt v3.3 handbook revision 2 43 the testbench uses a command word legality module that disables subaddresses 26 and 27 for transmit commands. for receive commands, subaddress 25 is disabled, and subaddress 27 is only enabled for word counts 1 to 9. "external command word legality example" on page 54 shows the source code for a command legality module implementing this behavior. the core1553b model sim ? library (in the mti/verif_rtl directory) contains compiled models for the complete environment. design source code of the top-level blocks is provided in the source directory to enable you to create your own simulation environment using this testbench as a starting point. examine the source files for qtbench and qrtsystem to obt ain a full understanding of the core operation. qtbench has a top-level generic, cmod e, that you can set to 0 or 1. wh en 0, the core is configured with wrttsw, wrtcmd, and extmdata set to '100'. when 1, these values are set to '011', and the backend module implements an address mapper function as described in "implementation hints" on page 53 . table 6-4 ? vhdl testbench modules entity source provided description qtbench yes the testbench top level. th is contains the bus control function and several remote terminals. qtbencdec no test block that emulates a bus controller. transmits 1553b command and data words and then decodes the status and data words generated by an rt in response. qbusmon no 1553b bus monitor. monitors the bus and reports on the bus traffic. qrtsystem yes hierarchical block with the core plus transceiver, backend, and command word legality blocks to the core. qbustransceiver no simply takes the six unidirectional signals from the core and models a transceiver connected to a bus. qtbbackend no connects to core backend interface and provides the following functions: implements an asynchronous 2k16 or 8k16 memory block, which provides the 32 receive and transmit subaddresses. has a built-in address mapping function. loops back the receive subaddress locations to the transmit memory. on a good message received, interrupts the correctly received words, which are copied from the rx subaddress to the tx subaddress. if the address mapp ing function is enabled, the ?synchronize with data? word is copied to the transmit vector word memory location. generates the interrupt acknowledge. cwlegality yes implements external command validity checking testbench operation and modification 44 revision 2 using the vhdl qtbencdec module you can instantiate the qtbencdec module in your design and use it to initiate 1553b messages. the top level of the module is shown in the code be low, along with a description of these ports ( table 6-5 ). entity qtbencdec is port ( clk16 : in std_logic; rstn : in std_logic; stopclk : in boolean; start : in boolean; qmsg : in tqmsgreq; busy : out boolean; qout : out tqmsgout; buspos : inout std_logic; busneg : inout std_logic ); end qtbencdec; to initiate a message, a simple record structure is set up and the start input is strobed. the module asserts busy until the 1553b message is completed and then deasserts busy. the qout record structure contains the data sent and received on the bus. the two record structures used here are shown in table 6-6 on page 45 and table 6-7 on page 45 . table 6-5 ? tbencdec port descriptions port dir. type function clk16 in std_logic clock source for the encoder and decoder; must be 16 mhz rstn in std_logic active low asynchronous reset; must be pulsed low at the start of simulation stopclk in boolean the encoder has an internal clock generator; when this input is true, the clock generator is halt ed. this allows the simulator to exit gracefully. this input ca n be tied permanently false to disable the stopclk feature. start in boolean this input is pulsed true to start a 1553b message. if it is not synchronized to a clock and only needs to be pulsed for a simulation delta cycle, use the following code: start <= true; wait for 0 ns; start <= false; qmsg in tqmsgreq input record structure that defines the message that will be transmitted; see below busy out boolean indicates that the encoder/decoder is busy qout out tqmsgout output record structure containing message data transmitted on the bus buspos inout std_logic connects to the positive side of the 1553b bus busneg inout std_logic connects to the negative side of the 1553b bus core1553brt v3.3 handbook revision 2 45 table 6-6 ? tmsgreq record structure element type default function rt integer, 0 to 31 0 command word rt value. broadcast is supported when the rt number is 31. tx integer, 0 to 1 0 command word tx value sa integer, 0 to 31 0 command word sa value mcwc integer, 0 to 32 0 word count or mode code value. for data transfers, values 1 to 32 should be used, and for mode codes, values 0 to 31. rtrt boolean false if true, an rt-to-rt command pair is transmitted. the transmit command word uses the rt, tx, and sa elements. rt2 integer, 0 to 31 0 rt command word value for the receive rt in rt-to- rt messages sa2 integer, 0 to 31 0 sa command word value for the receive rt in rt-to- rt messages data packet unknown, i.e., 'u' data to be transmitted for an rt receive message. this is an array(0 to 31) of word; word is std_logic_vector(15 down to 0). index 0 is used for mode code data. for example: data(0) <= "0000 1111 00001111"; data(1) <= to_word(16#1234#); data <= initdata(16#1000#); data <= initdata(16#5555#,0); the first example sets the first data word using standard vhdl assignments to std_logic_vector. the second example uses a function provided in one of the underlying core1553b packages to set the word to the hexadecimal value 1234. the third example uses another function call to set the complete data pattern to an incrementing value starting at 1000 hex. the final example sets the complete data pattern to 5555 hex. the second argument is the increment between consecutive data words. table 6-7 ? tqmsgout record structure structure element type function okay boolean indicates that the message wa s correctly processed with no errors. count integer number of words received cw1 word first command word cw2 word second command word. if no second command word, will contain '?' in all 16 bits. sw1 word first status word. if no status word, will contain '?' in all 16 bits. sw2 word second status word. if no status word, will contain '?' in all 16 bits (only for rtrt messages). data packet data packet for the message. when the rt is receiving, it will contain a copy of the transmitted data when transmitting the data the rt transmitted. on rt-to-rt messages, the data transferred between the rts will be provided. for mode codes, the data word will be in the first location, i.e., data(0). testbench operation and modification 46 revision 2 the vhdl code below shows a simple code fragment that generates a 10-word bc?to?rt 1 subaddress 5 message, with data increment ing from 1200 hex, which then displa ys the message. ?print_msgout? is a procedure provided in the underlyi ng core1553b package that displays the message details. it needs to pass the two record structures described above. signal busastart : boolean; signal busamsg : tqmsgreq; signal busabusy : boolean; signal busaout : tqmsgout; begin process begin busamsg.rt <= 1; busamsg.tx <= 0; busamsg.sa <= 5; busamsg.mcwc <= 10; busamsg.rtrt <= false; busamsg.data <= initdata(16#1200#); -- do the message busastart <= true; wait for 0 ns; busastart <= false; wait for 0 ns; while busabusy loop wait for 1 us; end loop; -- display the data transmitted print_msgout(busamsg,busaout); wait; end process; core1553brt v3.3 handbook revision 2 47 verilog testbench actel provides an example verilog testbench that you can use as the starting point for design verification of the core within your design. a blo ck diagram of the testbench is shown in figure 6-3 . the testbench creates an rt system (qrtsystem) by adding the backend inte rface and the command legality interface to the core. the t op level (qtbench) includes four of these cores. all the cores in this case are identical. table 6-8 on page 48 lists the source code modules. figure 6-3 ? verilog testbench backend cw legality core1553b rt 0 tcv 1553b busses core1553b rt 1 core1553b rt 2 core1553b rt 3 tcv tcv tcv tcv bus control (encoder and decoder) bus monitor bus control (encoder and decoder) bus monitor rt system rt system rt system rt system user control circuit backend cw legality backend cw legality backend cw legality tcv tcv tcv testbench operation and modification 48 revision 2 the testbench uses a command word legality module that disables subaddresses 26 and 27 for transmit commands. for receive commands, subaddress 25 is disabled, and subaddress 27 is only enabled for word counts 1 to 9. "external command word legality example" on page 54 gives the source code for a command legality module implementing this behavior. the core1553b model sim library (in the mti/user_vlog directory) contains compiled models for the complete environm ent. design source code of the top-level blo cks is provided (in the source directory) to enable you to create your own simulation environment using this testbench as a starting point. examine the source files for qtbench and qrtsystem to obtain a full understanding of the core operation. qtbench has a top-level parameter, cm ode, that can be set to 0 or 1. when 0, the core is configured with wrttsw, wrtcmd, and extmdata set to '100'. when 1, these values are set to '011', and the backend module implements an address mapper function as described in "implementation hints" on page 53 . table 6-8 ? verilog testbench modules module source provided description qtbench yes the testbench top level. this contains the bus control function and several remote terminals. qtbencdec no test block that emulates a bus controller. this transmits 1553b command and data words and then decodes the status and data words generated by an rt in response. qrtsystem yes hierarchical block with the co re plus a transceiver, backend, and command word legality block to the core qtbbackend yes this connects to the core backend interface and provides the following functions: 1. implements an asynchronous 2k16 or 8k16 memory block providing the 32 receive and transmit subaddresses. 2. has a built-in address mapping function. 3. loops back the receive subaddress locations to the transmit memory. on a good message received, interrupts the correctly received words copied from the rx subaddress to the tx subaddress. if the address mapping function is enabled, the ?synchronize with data ? word is copied to the transmit vector word memory location. 4. generates the interrupt acknowledge. cwlegality yes 5. implements external command validity checking core1553brt v3.3 handbook revision 2 49 using the verilog qtbencdec module you can instantiate the qtbencdec module in your design and use it to initiate 1553b messages. the top level of the module is shown below, along with a description of these ports ( testbench operation and modification 50 revision 2 required to transmit is 33 words. receive data is st robed out of the module. all 1553b data words are put out from this module. the code below shows a simple code fragment that generates a 30-word bc?to?rt 1 subaddress 10 message with data increment ing from 4,096 decimal. /************************************************************************/ // the bus controller modules // qtbencdec bca (.clk(clk), .rstn(rstn), .buspos(busapos), .busneg(busaneg), .txstrobe(bca_txstb), .txcw(bca_txcw), .txdata(bca_txdata), .rxstrobe(bca_rxstb), .rxstat(bca_rxstat), .rxdata(bca_rxdata), .busy(bca_busy) ); /************************************************************************/ // store the data put out by the decoder // // stat[3:0] = fromus burst error cw always @(posedge clk) begin if (bca_init==1'b1) bca_count = 0; if (bca_rxstb == 1'b1) begin bca_store[bca_count] = {bca_rxstat, bca_rxdata }; bca_count = bca_count+1; end end /************************************************************************/ // main test procedure // reg [15:0] cw; reg [15:0] dw; reg [ 4:0] rt5bit; integer i; integer rt; initial begin rstn = 1'b0; bca_txstb = 1'b0; // used to load a word into the transmitter bcb_txstb = 1'b0; bca_init = 1'b1; // used to reset the store pointer on the decoder bcb_init = 1'b1; #312700; @(negedge clk); rstn = 1'b1; $display("core1553brt verilog test harness production 19jan09"); $display("receive bc-rt 1 sa 10 wc 8 message on bus a"); cw = { 5'b00001, 1'b0, 5'b01010, 5'b01000 }; transmit_cw(0,cw); for ( i=1; i<=8; i=i+1) transmit_dw(0,4095+i); core1553brt v3.3 handbook revision 2 51 wait_to_complete(0); display_bus(0); #9000000; $display("transmit rt-bc 1 sa 10 wc 6 message on bus b"); cw = { 5'b00001, 1'b1, 5'b01010, 5'b00110 }; transmit_cw(1,cw); wait_to_complete(1); display_bus(1); #9000000; $display("get the vector word from each rt"); for (rt=0; rt<=3;rt=rt+1) begin rt5bit = rt; cw = { rt5bit, 1'b1, 5'b00000, 5'b10000 }; transmit_cw(0,cw); wait_to_complete(0); $display("rt %0d got sw %h got vw %h", rt,bca_store[1][15:0],bca_store[2][15:0]); #9000000; end #4000000; $display(" "); $display("simulation complete"); $display(" "); $stop; end endmodule revision 2 53 7 ? implementation hints you can configure core1553brt to provide backend interfaces for a variety of hardware and software requirements. the backend interface has been designed to simplify backend hardware design; the core supports both synchronous and asynchronous backends with bus arbitration and variable read and write strobe pulse widths. to accommodate software requirements, you can modi fy the backend address map and interrupt vectors with simple address mapping functions implemented in hardware (explained in "modifying the backend address map" on page 57 ). table 7-1 shows some typical applications and the core configurations required. table 7-1 ? typical core implementations type description parameters standard-cw a 2k16 memory buffer is used with 32 words of memory allocated for each tx and rx subaddress. the 1553b command word is written to memory locations unused by the mode code subaddresses. the system can read the command word value to determine the number of words that were received. wrttsw = 0 wrtcmd = 1 extmdata = 0 address mapper = no cw legality = no standard-tsw a 2k16 memory buffer is used with 32 words of memory allocated for each tx and rx subaddress. the core1553b tsw is written to memory locations unused by the mode code subaddresses. the system can read the tsw value to determine the number of words that were received. this implementation provides extra status information, such as the bus on which the message was received. wrttsw = 1 wrtcmd = 0 extmdata = 0 address mapper = no cw legality = no direct device no memory is used; the core1553brt backend directly connects to the device. in this case, all unused 1553b subaddresses should be invalidated. if the device only accepts a fixed number of data words, only that word count should be legal for the subaddress in use. should an error be detected, this will be indicated by the interrupt vector, and the data should be discarded. no command words or tsw values are written to memory. wrttsw = 0 wrtcmd = 0 extmdata = 0 address mapper = no cw legality = yes compatibility mode the memory alloca tion emulates another 1553b remote terminal, allowing software drivers to be reused. a backend address mapping function is implemented that reads and writes command and data words from and to the memory addresses used by the remote terminal that core1553brt is replacing. wrttsw = 0 wrtcmd = 1 extmdata = 1 address mapper = yes cw legality = maybe implementation hints 54 revision 2 external command word legality example the core provides thr ee ports (useextok, cmdval, and cmdoka y) that allow the legal command word set to be modified. when useextok is low, the core internally decides which command words are legal (the legal command word set is defined in the core1553brt mil-std-1553b remote terminal datasheet). when useextok is high, an exte rnal block decodes the cmdval outpu t and generates a cmdokay input to indicate legal command words. the vhdl and verilog code blocks below implement an external le gality checker that does the following: ? legalizes mode codes as per the core1553brt mil-std-1553b remote terminal datasheet ? disables transmits from subaddresses 26 and 27 ? disables receives to subaddress 25 ? only enables word counts 1 to 9 and receives to subaddress 27 the source files for these modules are provided in the source directory. the core allows 3 s for the legality block to decode cwval and generate the cmdokay value; this can be implemented within the fpga, as shown below. vhdl example library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity cwlegality is port ( cwval : in std_logic_vector(11 downto 0); cmdokay : out std_logic ); end cwlegality; architecture rtl of cwlegality is signal broadcast : std_logic; signal ismcode : std_logic; signal tx : std_logic; signal sa : std_logic_vector(4 downto 0); signal wcmc : std_logic_vector(4 downto 0); begin -- decode incoming value broadcast <= cwval(11); tx <= cwval(10); sa <= cwval(9 downto 5); wcmc <= cwval(4 downto 0); ismcode <= '1' when ( sa="00000" or sa="11111") else '0'; -- this process decodes the command word and sets cmdokay for legal command words. plegal: process (broadcast,tx,sa,wcmc,ismcode) variable ok : std_logic; variable muxsel : std_logic_vector(5 downto 0); begin if (ismcode='0') then -- data transfers muxsel := tx & sa; ok := '0'; -- default is disabled ------------------------------------------------------------------------ -- this case statement legalizes data transfers to certain subaddresses case muxsel is when "111010" => ok := '0'; -- sa 26 disabled for tx when "111011" => ok := '0'; -- sa 27 disabled for tx when "011001" => ok := '0'; -- sa 25 disabled for rx core1553brt v3.3 handbook revision 2 55 when "011011" => if wcmc>0 and wcmc <10 then -- sa 27 disabled for rx if wc>9 ok := '1'; end if ; when others => ok := '1'; -- legalize all other subaddresses end case ; ------------------------------------------------------------------------ -- broadcast transmits are not allowed; overrides above case statement if broadcast='1' and tx='1' then ok := '0'; -- broadcast transmit is not allowed end if ; else ------------------------------------------------------------------------ -- this case statement legalizes mode codes muxsel := tx & wcmc; ok := '1'; -- default is okay case muxsel is when "100000" => -- dynamic bus control ok := '0'; -- since we can?t do it, we message error when "100001" => -- synchronise when "100010" => -- transmit status word ok := not broadcast; when "100011" => -- initiate self-test; we set this because we provide bit word ok := '1'; when "100100" => -- transmitter shutdown when "100101" => -- override transmitter shutdown when "100110" => -- inhibit terminal flag when "100111" => -- override inhibit terminal flag when "101000" => -- reset remote terminal when "110000" => -- transmit vector word ok := not broadcast; when "010001" => -- synchronise with data when "110010" => -- transmit last command ok := not broadcast; when "110011" => -- transmit bit word ok := not broadcast; when "010100" => -- selected transmitter shutdown ok := '0'; when "010101" => -- override selected transmitter shutdown ok := '0'; when others => -- all other commands illegal ok := '0'; end case ; end if ; cmdokay <= ok; end process; end rtl; verilog example module cwlegality (cwval, cmdokay); input [11:0] cwval; output cmdokay; reg cmdokay; wire broadcast, ismcode, tx; wire [4:0] sa, wcmc; assign broadcast = cwval[11] ; // decode incoming value assign tx = cwval[10] ; assign sa = cwval[9:5] ; assign wcmc = cwval[4:0] ; assign ismcode = (sa == 5'b00000 | sa == 5'b11111) ? 1'b1 : 1'b0 ; always @(broadcast or tx or sa or wcmc or ismcode) implementation hints 56 revision 2 begin : plegal reg ok; reg [5:0] muxsel; if (ismcode == 1'b0) begin muxsel = {tx, sa}; // data transfers ok = 1'b0; // this case statement legalizes data transfers to certain subaddresses case (muxsel) 6'b111010 : ok = 1'b0; // sa 26 disabled for tx 6'b111011 : ok = 1'b0; // sa 27 disabled for tx 6'b011001 : ok = 1'b0; // sa 25 disabled for rx 6'b011011 : ok = (wcmc > 0 & wcmc < 10); // sa 27 disabled for rx if wc>9 default : ok = 1'b1; // legalize all other subaddresses endcase // broadcast transmits are not allowed; overrides above case statement if (broadcast == 1'b1 & tx == 1'b1) ok = 1'b0; // broadcast transmit is not allowed end else begin //---------------------------------------------------------------- // this case statement legalizes mode codes muxsel = {tx, wcmc}; ok = 1'b1; case (muxsel) 6'b100000 : // dynamic bus control ok = 1'b0; // since we can?t do it, we message error 6'b100001 : // synchronize 6'b100010 : // transmit status word ok = ~broadcast; 6'b100011 : // initiate self-test; we set this because we provide bit word ok = 1'b1; 6'b100100 : // transmitter shutdown 6'b100101 : // override transmitter shutdown 6'b100110 : // inhibit terminal flag 6'b100111 : // override inhibit terminal flag 6'b101000 : // reset remote terminal 6'b110000 : // transmit vector word ok = ~broadcast; 6'b010001 : // synchronise with data 6'b110010 : // transmit last command ok = ~broadcast; 6'b110011 : // transmit bit word ok = ~broadcast; 6'b010100 : // selected transmitter shutdown ok = 1'b0; 6'b010101 : // override selected transmitter shutdown ok = 1'b0; default : // all other commands illegal ok = 1'b0; endcase end cmdokay <= ok ; end endmodule core1553brt v3.3 handbook revision 2 57 modifying the backend address map the default setting of core1553brt creates 32 receiv e and 32 transmit subaddresses, each with 32 words of memory, which in turn requires 2,048 words of memory. receive subaddresses 0 and 31 are used for storing either the 1553b command word or the tsw value. you can use an external address mapping function to modify the backend address map to match the software models of legacy 1553b remote terminals, allowing software drivers to be reused ( figure 7-1 ). you can use the cmdval output to generate the mapped address function; however, it must be externally latched using the addrlat signal (addrlat is an active high enable for an external d-type flip-flop). a typical address mapping function, given below, remaps the backend memory map to an 8 k word memory. each subaddress is allocated 64 words, and separate buffers are provided for both broadcast and non-broadcast receive/transmit. each non-mode-code subaddress consists of 64 word s; the command word or tsw value is written to location 0, and the associated data words are stored at locations 32 to 63. for the mode code subaddresses, the command word or tsw value is written to location 0 plus the mode code value, and the data word is stored at loca tion 32 plus the mode code value. for the ?transmit vector word? command, the command word is stored in location 16, and the vector word is read from location 48. for the ?synchronize with data? command, the command word is stored at location 17 and the data written to location 49. note that separate address spaces exist for transmit and receive mode codes and broadcast transmit and receive mode codes. this mapping function is very small; it requires only 23 logic modules in the actel sx-a and rtsx-s families. consider the code below. vhdl address mapping function entity addressmapper is port ( clk : in std_logic; addrlat : in std_logic; cmdval : in std_logic_vector(11 downto 0); memaddr : in std_logic_vector(10 downto 0); memoper : in std_logic_vector( 1 downto 0); mapaddr : out std_logic_vector(12 downto 0) ); end addressmapper; architecture rtl of addressmapper is signal cmdaddr : std_logic_vector(11 downto 0); begin process (clk) begin if clk'event and clk='1' then if addrlat='1' then figure 7-1 ? external address mapper circuit q q d l addrlat clk1553 cmdval memaddr memoper address mapper function mapped address set clr implementation hints 58 revision 2 cmdaddr <= cmdval; end if ; end if ; end process ; process (cmdaddr,memaddr,memoper) variable sa : std_logic_vector(4 downto 0); variable wccw : std_logic_vector(4 downto 0); variable wcad : std_logic_vector(4 downto 0); variable mc : std_logic; variable bcast : std_logic; variable tx : std_logic; variable msel : std_logic_vector( 2 downto 0); begin sa := cmdaddr(9 downto 5); wccw := cmdaddr(4 downto 0); wcad := memaddr(4 downto 0); bcast := cmdaddr(11); tx := cmdaddr(10); if (sa="00000" or sa="11111") then mc := '1'; else mc := '0'; end if ; msel := memoper & mc; case msel is when "100" => mapaddr <= bcast & tx & sa & '0' & "00000"; -- cw data transfer when "101" => mapaddr <= bcast & tx & sa & '0' & wccw; -- cw mode code when "000" => mapaddr <= bcast & tx & sa & '1' & wcad; -- dw transfer when "001" => mapaddr <= bcast & tx & sa & '1' & wccw; -- dw mode code when others => mapaddr <= ( others => '-'); end case ; end process; end rtl; verilog address mapping function module addressmapper (clk, addrlat, cmdval, memaddr, memoper, mapaddr); input clk; input addrlat; input [11:0] cmdval; input [10:0] memaddr; input [1:0] memoper; output [12:0] mapaddr; reg [12:0] mapaddr; reg [11:0] cmdaddr; always @( posedge clk) begin if (addrlat == 1'b1) cmdaddr <= cmdval ; end always @(cmdaddr or memaddr or memoper) begin reg [4:0] sa; reg [4:0] wccw; reg [4:0] wcad; reg mc; reg bcast; reg tx; reg [2:0] msel; sa = cmdaddr[9:5]; wccw = cmdaddr[4:0]; core1553brt v3.3 handbook revision 2 59 wcad = memaddr[4:0]; bcast = cmdaddr[11]; tx = cmdaddr[10]; if (sa == 5'b00000 | sa == 5'b11111) mc = 1'b1; else mc = 1'b0; msel = {memoper, mc}; case (msel) 3'b100 : mapaddr <= {bcast, tx, sa, 1'b0, 5'b00000} ; // command data transfer 3'b101 : mapaddr <= {bcast, tx, sa, 1'b0, wccw} ; // command mode code 3'b000 : mapaddr <= {bcast, tx, sa, 1'b1, wcad} ; // data data transfer 3'b001 : mapaddr <= {bcast, tx, sa, 1'b1, wccw} ; // data mode code transfer default : mapaddr <= {13{1'bx}} ; endcase end endmodule modifying the backend interrupt vector the default setting of core1553brt creates a 6-bit interrupt vector, which indicates whether or not a good message was received. it is also used for a tran smitter subaddress. if in tenbbr (interrupt enable bad block received) is high, interrupts are generated for good and bad 1553b messages. when intenbbr is low, interrupts are only generated for messages that are received or transmitted correctly. an external interrupt mapping function can be used to add extra information to the interrupt vector ( figure 7-2 ), such as the received word count. it will also tell you whether the command was broadcast. the cmdval output can be used to generate this ex tra information; however, it must be externally latched using the intlat signal (intlat is an active high enable for an external d-type flip-flop). the interrupt mapping function below creates vector information, indicating broadcast and the received word count value. if an extended interrupt vector is then generated, the need for the system to read the tsw or command word from memory is removed. th e interrupt vector provides subaddress, word count data, and an indication that the message was good. in this case, the wrttsw and wrtcmd inputs can be tied low. figure 7-2 ? external interrupt vector extender circuit q q d l intlat clk1553 cmdval intvect interrupt vector extender extended interrupt vector set clr implementation hints 60 revision 2 consider the verilog extended interrupt vector generation example below: module intvectextender (clk, intlat, cmdval, intvect, mapvect); input clk; input intlat; input [11:0] cmdval; input [6:0] intvect; output [12:0] mapvect; reg [12:0] mapvect; reg [11:0] cmdint; always @( posedge clk) begin if (intlat == 1'b1) cmdint <= cmdval ; end always @(cmdint or intvect) begin reg [4:0] sa; reg [4:0] wc; reg bcast; reg tx; reg gbr; wc = cmdint[4:0]; bcast = cmdint[11]; gbr = intvect[6]; tx = intvect[5]; sa = intvect[4:0]; mapvect <= {gbr, bcast, tx, sa, wc} ; end endmodule or, if you are using vhdl, consider the vhdl extended interrupt generation function example code: library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity intvectextender is port ( clk : in std_logic; intlat : in std_logic; cmdval : in std_logic_vector(11 downto 0); intvect : in std_logic_vector( 6 downto 0); mapvect : out std_logic_vector(12 downto 0) ); end intvectextender; architecture rtl of intvectextender is signal cmdint : std_logic_vector(11 downto 0); begin process (clk) begin if clk'event and clk='1' then if intlat='1' then cmdint <= cmdval; end if ; end if ; end process ; process (cmdint,intvect) variable sa : std_logic_vector(4 downto 0); variable wc : std_logic_vector(4 downto 0); variable bcast : std_logic; core1553brt v3.3 handbook revision 2 61 variable tx : std_logic; variable gbr : std_logic; begin wc := cmdint(4 downto 0); bcast := cmdint(11); gbr := intvect(6); tx := intvect(5); sa := intvect(4 downto 0); mapvect <= gbr & bcast & tx & sa & wc; end process ; end rtl; connecting the backend to internal fpga memory when implementing the core in flash-based fpga or axcelerator devices, you can directly connect the core to the flash-based fpga or axcelerator memo ry blocks. use two memory blocks (1k16 each?one for transmit and the other for receive memory), as shown in figure 7-3 . the core must be in synchronous mode (asyncif inactive?low). the memgntn input should be tied active (low) and the memwaitn input inactive (high ). this allows the backend to have immediate access to the memory blocks. buffer management the core implements basic buffer management tec hniques for the 1553b message protocol. receive and transmit buffers are provided. this approach require s the backend system to empty and fill the buffers promptly. for a ?broadcast receive? command, the core generates an interrupt, indicating that a receive buffer is available as the last data word is written to memory. at the same time, another receive command to the same subaddress could be on the bus, which causes the first word in the memory to be overwritten within 20 s, depending on the backend request grant times. this time could be reduced to less than 5 s if the backend delays the core?s access to the memory for the last data word. it also allows immediate access for the first data word in the following message. figure 7-3 ? using internal fpga ram modules rx memory read write busainen busainp busainn busainh busaoutp busaoutn busbinen busbinp busbin busainh busboutp busboutn tx memory read write actel fpga backend interface command legality checker command legality interface core1553brt implementation hints 62 revision 2 the following implementation ( figure 7-4 on page 62 ) implements an extra buffer level in the backend. the core writes the received data to the small 32 16 memory block. at the end of the transfer, the backend rx state machine captures the tsw value, then bursts the complete receive packet into main memory. this system enables the complete messa ge to be copied to main memory once completely validated. it will stay intact in main memory until the complete following message of at least 40 s is received. buffer management techniques are system-dependent. they depend on the bus traffic scheduling by the bus controllers. the core1553brt implementation is in tended to provide a flexib le interface that can be adapted to the system requirements. bus transceivers core1553brt does not include the transceiver that is required to drive the 1553b bus. core1553brt is designed to interface directly to mil-std-1553 transceivers. there are several suppliers of mil-std- 1553 transceivers, such as ddc (b u-63147) and aeroflex (act4402). when using fusion, igloo/e, proasic3/e, proasic plus , or axcelerator fpgas, level translators are required to connect the 5 v outputs of the 1553 b transceivers to the 3.3 v inputs of the fpga. in addition to the transceiver, a pulse transformer is required for interfacing to the 1553b bus. figure 7-5 on page 63 and figure 7-6 on page 64 show the connections required from core1553brt to the transceivers and then to the bus via pulse transformers. figure 7-4 ? buffer management circuit rx state machine rx buffer 3216 tx memory 2k16 write read command legality checker command legality interface backend interface write read busainen busainp busainn busainh busaoutp busaoutn busbinen busbinp busbin busainh busboutp busboutn core1553brt core1553brt v3.3 handbook revision 2 63 typical rt systems core1553brt can be used in systems with and without backend memory. figure 7-5 shows a typical implementation for a system with backend memory and a cpu to process the messages. figure 7-6 on page 64 shows a system with direct connection between core1553brt and external analog to digital converters, etc. in this case, any glue logic requ ired between the core and the device being interfaced to can simply be implemented within the fpga containing the core. figure 7-5 ? typical cpu- and memory-based rt system memory backend interface command legality interface command legality checker busainen rcvstba busainp rxdainp busbinen rcvstba busbinp rxdbinp busbinn rxdbinn busboutinh txinha busainn rxdainn busaoutinh txinha busaoutp txdainp busboutp txdbinp busaoutn txdainn busboutn txdbinn transceiver core1553brt actel fpga implementation hints 64 revision 2 figure 7-6 ? typical non-memory-based rt system adc dac glue logic backend interface command legality interface command legality interface busainen rcvstba busainp rxdainp busbinen rcvstba busbinp rxdbinp busbinn rxdbinn busboutinh txinha busainn rxdainn busaoutinh txinha busaoutp txdainp busboutp txdbinp busaoutn txdainn busboutn txdbinn transceiver core1553brt actel fpga revision 2 65 8 ? vhdl testbench procedure and function calls both the verification and vhdl user testbenches pr ovided with the core include some low-level support routines that you can use to verify your 1553brt. these are availabl e in the three packages that can be accessed by adding the following four lines to your vhdl source code: library core1553b; use core1553b.misc.all; use core1553b.textio.all; use core1553b.test1553b.all; these routines make use of the following types, which are also declared in these packages: subtype int1bit is integer range 0 to 1; subtype int5bit is integer range 0 to 31; subtype nibble is std_logic_vector ( 3 downto 0); subtype byte is std_logic_vector ( 7 downto 0); subtype word is std_logic_vector (15 downto 0); type byte_array is array ( integer range <>) of byte; type word_array is array ( integer range <>) of word; type packet is array ( integer range 0 to 31) of word; the two record structures used in the encoder decoder module are as follows: type tqmsgreq is record rt : int5bit; tx : int1bit; sa : int5bit; mcwc : integer range 0 to 32; rtrt : boolean; rt2 : int5bit; sa2 : int5bit; data : packet; end record; type tqmsgout is record okay : boolean; count : integer; cw1 : word; cw2 : word; sw1 : word; sw2 : word; data : packet; end record; the following type conversion routines are provided to convert between integer, std_logic, and boolean types: function to_slv1bit( x: int1bit ) return std_logic_vector; function to_sl1bit( x: int1bit ) return std_logic; function to_slv5bit( x: int5bit ) return std_logic_vector; function to_int1bit( x: boolean ) return int1bit; function to_int1bit( x: std_logic ) return int1bit; function to_int1bit( x: std_logic_vector ) return int1bit; function to_int5bit( x: std_logic_vector ) return int5bit; function to_byte ( x : integer ) return byte; function to_word ( x : integer ) return word; vhdl testbench procedure and function calls 66 revision 2 the following function call is provided to create da ta patterns. this returns a data packet whose first value is set to the seed value and whose subsequent values are incremented by the delta value. if the delta value is zero, all values are the same. for example: function initdata( seed : integer; delta : integer) return packet; a procedure is provided that compares data packets and displays the error when the compare fails. for example: procedure comparepacket( str : string; exp : packet; got : packet; len : integer; errcnt : inout integer ); the first parameter is a text string that is print ed when a failure occurs, the second parameter is the expected data, and the third parameter is the actual data. the fourth parameter indicates how many of the words are to be compared (the packet contains 32 words). finally, the fifth parameter is a global error counter that is increment ed if a compare fails. a procedure is provided that displays the received message record structure. this procedure requires both the message request and output record structures so that it can format th e printed data correctly. for example: procedure print_msgout( qmsg : tqmsgreq; q : tqmsgout); to support general printing, a printf routine is provided that supports printing std_logic, boolean, integer, and std_logic_vector types. the syntax is slightly different from the c-language printf function. for example: printf("hello world decimal %d hex %x hex4 %04x bits %04b a string %s", fmt(256)&fmt(word)&fmt(word)&fmt(nibble)&fmt(string)); prints hello world decimal 256 hex 100 hex4 0100 bits 1010 a string thestring revision 2 67 a ? list of changes the following table lists critical changes that were made in each revision of the document. date changes page revision 2 (august 2010) the core version changed from v3.2 to v3.3. 7 information relating to the external bist interface was added at the end of the "general description" section . 5 figure 2-1 ? core1553brt conf iguration within smartdesign was replaced. 11 the initlastsw and external_bist parameters were added to table 3-1 ? core1553brt parameters . 13 the description for rtaddr[ 4:0] was re vised in table 3-2 ? 1553b bus interface . 15 the following port names were added to table 3-3 ? control and status signals : ? purstn ? bitinen ? bitin[15:0] 15 the description for cmdstb was revised in table 3-4 ? command legalization interface . 17 in table 5-6 ? bit word , the value of bits [4:0] for core1553brt v3.3 was added. 34 the "connecting the backend to internal fpga memory" section was revised to change "proasic3 or axcelerator devices" to "flash-based fpga or axcelerator devices." 61 revision 2 69 b ? product support actel backs its products with various support services includi ng customer service, a customer technical support center, a web site, an ftp site, electronic mail, and worldwide sales offices. this appendix contains information about contacting actel and using these support services. customer service contact customer service for non-technical product su pport, such as product pricing, product upgrades, update information, order st atus, and authorization. from northeast and north central u.s.a., call 650.318.4480 from southeast and s outhwest u.s.a., call 650. 318.4480 from south central u.s.a., call 650.318.4434 from northwest u.s.a., call 650.318.4434 from canada, call 650.318.4480 from europe, call 650.318.4252 or +44 (0) 1276 401 500 from japan, call 650.318.4743 from the rest of the world, call 650.318.4743 fax, from anywhere in the world 650.318.8044 actel customer technical support center actel staffs its customer technical support center with highly skilled engineers who can help answer your hardware, software, and design questions. the customer technical support center spends a great deal of time creating application notes and answers to faqs. so, before you contact us, please visit our online resources. it is very likely we have already answered your questions. actel technical support visit the actel customer support website ( www.actel.com/support/search/default.aspx ) for more information and support. many answers available on the searchable web resource include diagrams, illustrations, and links to other resources on the actel web site. website you can browse a variety of technical and non -technical information on actel?s home page, at www.actel.com . contacting the customer technical support center highly skilled engineers staff the technical support c enter from 7:00 a.m. to 6:00 p.m., pacific time, monday through friday. several ways of contacting the center follow: email you can communicate your technical questions to ou r email address and receive answers back by email, fax, or phone. also, if you have design problems, y ou can email your design files to receive assistance. we constantly monitor the email account throughout the day. when sending your request to us, please be sure to include your full name, company name, and your contact information for efficient processing of your request. product support 70 revision 2 the technical support email address is tech@actel.com . phone our technical support center answers all calls. th e center retrieves informa tion, such as your name, company name, phone number and your question, and then issues a case number. the center then forwards the information to a queue where the first available application engineer receives the data and returns your call. the phone hours are from 7:00 a.m. to 6:00 p.m., pacific time, monday through friday. the technical support numbers are: 650.318.4460 800.262.1060 customers needing assistance outside the us time zones can either contact technical support via email (tech@actel.com) or contact a local sales office. sales office listings can be found on the website at www.actel.com/company/contact/default.aspx . revision 2 71 index a actel electronic mail 69 telephone 70 web-based technical support 69 website 69 b backend access times 30 address map, modifying 57 interface 6 , 18 interrupt vector, modifying 59 behavioral simulation 37 bit word 34 block diagram 6 buffer management 61 circuit 62 built-in test (bit) 34 word 34 bus controller 9 controller modules 50 overview 9 signals 15 transceivers 62 c clocks 6 requirements 26 cmdval encoding 35 command legalization interface 17 , 35 internal block 6 command words 6 , 9 format 10 storage 29 contacting actel customer service 69 electronic mail 69 telephone 70 web-based technical support 69 customer service 69 d data transfers receive 31 transmit 31 data words 6 , 9 format 10 decoders 6 delay loopback 26 device requirements 8 utilization and performance 8 digital pll 6 e encoders 6 error detection 33 example external command word legality 54 external address mapper circuit 57 external command word legality, example 54 external interrupt vector extender circuit 59 f fpga memory 61 g general description 5 h hints 53 i i/o signals 15 implementation hints 53 interactive operation 40 interface timing 21 internal fpga memory 61 interrupt vector extension 29 l loopback delay 26 fail logic 6 tests 32 m main test procedure 50 manchester encoding 6 memory 5 address map 19 , 27 messages formats 9 parameters 40 types 9 mil-std-1553b bus 9 index 72 revision 2 mode codes 5 , 31 p parameters 13 parity 6 performance, device 8 pll 6 product support 70 customer service 69 electronic mail 69 technical support 69 telephone 70 website 69 r remote terminal 9 requirements clocks 26 device 8 rxstat value definitions 49 s signals backend 18 bus 15 command legalization interface 17 control and status 15 i/o 15 specifications interface timing 21 state machines, fail-safe 7 status words 9 formats 10 settings 29 t technical support 69 testbench verification 37 verilog 47 vhdl 42 vhdl procedure and function calls 65 timing 21 tool flows 11 transfer status words 30 transfers rt-to-rt 31 typical core implementations 53 typical rt systems 63 typical system 5 u utilization, device 8 v verification and compliance 7 verification testbench 37 menu summary 39 menus 39 rt configurations 37 , 38 tests 41 verilog qtbencdec module 49 tbencdec port descriptions 49 testbench 47 testbench modules 48 version 7 vhdl qtbencdec module 44 tbencdec port descriptions 44 testbench 42 testbench procedure and function calls 65 tmsgreq record structure 45 tqmsgout record structure 45 w web-based technical support 69 word formats 10 50200093-2/8.10 actel corporation 2061 stierlin court mountain view, ca 94043-4655 usa phone 650.318.4200 fax 650.318.4600 actel europe ltd. river court,meadows business park station approach, blackwater camberley surrey gu17 9ab united kingdom phone +44 (0) 1276 609 300 fax +44 (0) 1276 607 540 actel japan exos ebisu buillding 4f 1-24-14 ebisu shibuya-ku tokyo 150 japan phone +81.03.3445.7671 fax +81.03.3445.7668 http://jp.actel.com actel hong kong room 2107, china resources building 26 harbour road wanchai, hong kong phone +852 2185 6460 fax +852 2185 6488 www.actel.com.cn actel is the leader in low power fpgas and mixed signa l fpgas and offers the most comprehensive portfolio of system and power management solutions. po wer matters. learn more at www.actel.com. ? 2010 actel corporation. all rights reserved. actel, actel fusion, igloo, libero, pigeon point, proasic, smartfusion and the a ssociated logos are trademarks or registered trademarks of actel corporation. all other trademarks and service marks are the property of their resp ective owners. |
Price & Availability of CORE1553BRT-RC
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |